1. Field of the Invention
The present invention relates to a key event controlling apparatus, and more relates particularly to a key event controlling apparatus for changing the destination to deliver specific key events and performing filtering of key events.
2. Background of the Related Art
In a window system such as XWindowSystem™ (a registered trademark of Massachusetts Institute of Technology), which is a popular mechanism for managing key states and notifying changes in the states, a virtual key event is issued when a modifier key such as a shift key or a control key is combined with another key, in accordance with the key operation (see, for example, “XWindow handbook”, ASCII corporation, 1990”, Oliver JONES, supervised by Ryo NISHIMURA, translated by Akemi MIURA, (hereinafter referred to as “Non-patent Document 1”)).
A technique of event managing on a window system that handles a plurality of windows is a multi-window event management device which realizes automatic switching of a focus window, as a destination to which to notify events, by universally managing information concerning window control (see, for example, Japanese Patent Laid-Open Publication No. 2-139626 (hereinafter referred to as “Patent Document 1”)).
However, the techniques described in Non-patent Document 1 and Patent Document 1 do not take into consideration the case where functional assignments of keys are to be changed based on the periods of time for which the keys are pressed, e.g., a short press (a so-called “click”) or a long press (a so-called “hold”), or based on the ways of operating keys, e.g., a half press or a full press.
An example of mechanism for changing functional assignments of keys based on the periods of time for which the keys are pressed, e.g., the short press or the long press, is a mechanism which notifies different events in accordance with the key operation, depending on whether it is a short press or a long press (see, for example, Japanese Patent Laid-Open Publication No. 2000-353357 (hereinafter referred to as “Patent Document 2”)).
In the situation where different functions are to be assigned in accordance with the key operation depending on whether it is a short press or a long press, there may be a case where it is desirous to suppress short press events once a long press has been ascertained. There may also be a case where short press events need to be notified even after a long press has been ascertained. In the case where a certain operation is to be performed when a key is first pressed, and a next operation is to be performed when a long press is ascertained thereafter, it would be necessary to notify short events even after a long press has been ascertained. One example thereof would be the case where a scroll is begun when a key is pressed, and the scroll speed is increased when a long press has been ascertained (see, for example, Japanese Patent Laid-Open Publication No. 2003-162356).
In this case, the key delivering device functioning to notify changes in the states of keys would notify the state of the corresponding key or virtual key in the middle of a key operation, even before a corresponding virtual key is determined following completion of a series of key operations. For example, a sequence in the case where a virtual key “long-pressed key” and a virtual key “short-pressed key” are assigned to a long press and a short press of a given key is shown in FIG. 21, where it is assumed that the key is long-pressed. First, at the time the key is pressed, the key delivering device notifies a change in the state of the “short-pressed” virtual key. Neither the short-pressed key nor the long-pressed key is unequivocally ascertained at the time of this key pressing, since it is still in the middle of the key operation. Thereafter, once a certain period of time elapses with the key being pressed, thereby resulting in the ascertainment of a long press operation, this method notifies a change in the state of the “long-pressed” virtual key. According to the above method, each application receives a notification of a virtual key event even before the ascertainment of a key operation. Therefore, according to this method, a received series of virtual key events are subjected to a comprehensive determination at the application side to determine which key event has been ascertained, and a corresponding process is performed.
As for grabbing of key events, the widely-prevalent XWindowSystem realizes it as follows. When a key that is a target of grabbing is pressed, the destination to which to deliver the key event is switched from an application which is active to that which has requested grabbing, and the delivery path is brought back to normal when the key is released (see, for example, the aforementioned Non-patent Document 1).
There may also be a case where a user performs a process for not only a particular application but all existing applications. A specific example would be the case where all applications close, minimize, or maximize the screens displayed thereby. In such a case, since generally-used window systems do not have a mechanism for delivering key events to all windows, a window manager for managing windows is provided, such that a universal operation request is notified to the window manger, which, having received the above, performs operations to all windows. However, the operations to be performed to all windows by a generally-used window manager, such as FVWM, are limited to operations concerning the windows themselves, e.g., maximize or minimize window, due to the nature of window managing (see, for example, David Fries, et al., “The Official FVWM Homepage”, Jul. 20, 2002, searched as of Sep. 9, 2002, <www.fvwm.org>”).
As a complement to the above, there exists an input device which, when text characters are to be simultaneously inputted to a plurality of windows, outputs the respective input characters to corresponding windows by referring to a character-window correspondence table which describes correspondence between inputted characters and destination windows where the inputted characters are to be inputted (see, for example, Japanese Patent Laid-Open Publication No. 8-50542).
However, the aforementioned conventional technique has a first problem in that, when a plurality of key events which are issued through a series of key operations are delivered, as a result of grabbing of key events, to both an application which is designated by the user or an application to be the destination of key event delivery (hereinafter referred to as the “active application”) and the application which is a recipient of presidential delivery (hereinafter referred to as the “grabbing application”), only a portion of the series of key operations is notified to each application, thereby making it impossible to accurately ascertain the function, so that the system may perform an unexpected operation.
For instance, a sequence in the case where “long-pressed” and “short-pressed” virtual keys are assigned to a given key, and application A is an active application and application B is a grab application for the “long-pressed” virtual key, is shown in FIG. 22, where it is assumed that the key is long-pressed. First, when the key is pressed, a “short-pressed” virtual key press event is notified to application A. Next, a “long-pressed” virtual key press event is notified to application B. Thereafter, when the key is released, a “short-pressed” virtual key release event is notified to application A, and a “long-pressed” virtual key release event is notified to application B. Although the key operation would prove to be a long press once all of the series of four virtual key events are received, application A has only received a notification of the “short-pressed” virtual key event; therefore, it will perform a process corresponding to a short press although the user has not performed a short press operation.
It might be conceivable to solve the aforementioned problem, where “long-pressed” and “short-pressed” virtual keys are assigned to a key, by not issuing a press event at the time the key is pressed because the user's operation result cannot be ascertained, and only issuing a “long-pressed” or “short-pressed” virtual key release event corresponding to the operation result at the time of the key release, when the key operation result becomes ascertained. However, since this method does not issue a keypress event for any key that supports a long press, different types of key event will be issued between keys which do not support long-press operation and keys which support long-press operation. This results in a problem in that, each time a key which supports long-press operation is altered, any application which is to process key events concerning it would also have to be altered. In order to cope with this problem, it might be conceivable to not issue key press events even for keys which do not support long-press operation, but such a method will introduce a delay in the key events for every key, thus detracting from the operability on the part of the user.
There is also a second problem in that, when a specific key is to be grabbed in a generally-used window system such as XWindowSystem, the delivery destination of key events is switched to the recipient of precedential delivery once that key is pressed and until the time it is released. Therefore, depending on the order of virtual key delivery, those key events which are not even the target of grabbing may also be delivered to the recipient of precedential delivery.
For instance, a sequence in the case where “long-pressed” and “short-pressed” virtual keys are assigned to a given key, and application A is an active application and application B is a grab application which grabs the “short-pressed” virtual key, is shown in FIG. 23, where it is assumed that the key is long-pressed. Since the key events from the “long-pressed” virtual key press event to the “long-pressed” virtual key release event are to be delivered to application B, if the virtual key events are issued in the order of a “short-pressed” virtual key press event, a “long-pressed” virtual key press event, a “short-pressed” virtual key release event, and a “long-pressed” virtual key release event, even the “short-pressed” virtual key release event will be sent to application B. This means that no key release will be notified to application A.
A possible method for preventing such an improper delivery of key events due to grabbing might be not performing any grabbing, so that key events are always delivered to the active application, where the active application subjects the delivered key events to a comprehensive determination to switch processing or notify to other applications. However, this has a problem in that, if it is desirous to perform a particular process for a particular key operation over the entire system in a unified manner, it will be necessary for every application which can potentially become an active application to support the above improvement, which would result in an increase in the development overhead. Moreover, in the case where an application which does not support the above improvement is introduced, e.g., an open application which has been developed by a third party, any key operation related to the above improvement will prove invalid on such an application. For example, in the case where the entire system is to universally transition to a manner mode in response to a long press of a manner key, every application will need to handle the processing of manner mode transition in response to the notification of a long press of the manner key. Furthermore, on a downloaded piece of open software which does not include a description of the above processing, the long press of the manner key will be invalid, or a different process may be performed.
There is also a third problem in that, in a generally-used window system such as XWindowSystem, in order to avoid conflicts between grabbings, only the window which was the first to make a request is allowed to become a recipient of presidential delivery for a given key. In other words, it is not possible for a plurality of windows to grab key events concerning the same key at the same time.
There is also a fourth problem in that, in the case where the user wishes to perform a universal process for all windows, with the aforementioned conventional technique in which a window manager is in charge of management and control, it is impossible to perform any process which is not an operation concerning the windows themselves for all windows, e.g., a process of undoing an immediately previous operation and restoring the immediately preceding state, or a data save process.
The earlier-mentioned conventional technique concerning an input device directed to a plurality of windows (e.g., see Patent Document 2 above) only envisages text input; furthermore, a notified text input is delivered to a plurality of windows merely in accordance with a character-window correspondence table. Therefore, in the case where a plurality of key events are generated during the user's key operation process, all of the generated key events will be respectively delivered to the corresponding windows, thus resulting in the aforementioned first problem of the system performing an unexpected operation.